\section{Introduction}
\label{section:introduction}

The sprawling complexity of software systems has lead many organizations to
adopt \emph{software product line techniques} to manage large portfolios of
similar products.  For example, modern cars use software to achieve a
large variety of functionality, from power train control to infotainment.  To
organize and manage the huge variety of software subsystems, many car
manufacturers, such as General Motors (GM), make extensive use of software
product line engineering techniques~\cite{flores13}.

At the same time, \emph{model-based techniques} are also actively used by
companies, especially in domains such as automotive and aerospace, as a way to
increase the level of abstraction and allow engineers to develop systems in
notations they feel comfortable working with~\cite{pretschner07}.  That also
entails the active use of \emph{model transformations} -- operations for
manipulating models in order to produce other models or generate code.

Currently, GM is going through the process of migrating models from a legacy
metamodel to AUTOSAR~\cite{systemp}.  In previous work, we have presented the
transformation \gmtoautosar~\cite{GMcasestudy}. Given a single GM legacy model,
\gmtoautosar produces a single AUTOSAR output model, based on a set of
requirements followed by GM engineers.  In order to study its correctness,
\gmtoautosar was implemented in DSLTrans~\cite{selimICGT2014,Lucio:10}, a model
transformation language that specializes in helping developers create provably
correct transformations. 


Because of the extensive use of product lines, 
the entire product line of legacy models 
needs to be migrated to a new 
product line of AUTOSAR models.
% GM is now faced with the problem
% of migrating an entire product line of legacy models to a new product line of
% AUTOSAR models. 
To do this, GM engineers need to create purpose-specific migration
transformations.
%% However, the state of practice does not facilitate doing this on the grand
%% scale.   
Yet transforming product lines is inherently difficult: the relationships
between the products need to be preserved, and a variety of
properties between the input and output models 
in the transformation need to be established.
Thus, the task of a
 product-line level transformation is  not
only to maintain relationships between the features and relationships between
the products but also to make sure that the transformation maintains certain
properties, expressed in terms of pre- and post- conditions.  
Existing tools and methodologies do not facilitate model transformations
in the context of product lines.


In our earlier work~\cite{salay14}, 
we presented a technique for {\em ``lifting''} a class of
%% graph-rewriting-based~\cite{ehrig06}
model transformations so that they can be
applied to software product lines.  \emph{Lifting} here means
\emph{reinterpretation} of a transformation so that instead of
a single product, it applies to the entire product line.  
\mf{\bf ADDED per reviewer 1 comment:}
This requires lifting of the transformation \emph{engine} to implement lifting
semantics. Thus, existing transformations can be applied without modification to
product lines using the lifted transformation engine.

The goal of this paper is to demonstrate, using an empirical case study
from an automotive domain, that it is tractable to lift industrial-grade
transformations.
%% We postulate that it is tractable to make
%% industrial-grade transformations variability-aware via lifting. 
%% %
%% In this paper, we present an empirical case study from the automotive domain to
%% test this theory. 
%% %
Specifically, we report on an experience of lifting a previously published transformation~\cite{GMcasestudy}, \gmtoautosar, 
used in the context of automotive software and applying it to a realistic product
line.
We lifted \gmtoautosar using the theory of lifting presented in~\cite{salay14}.
In order to do this, we had to adapt parts of the existing
model transformation engine,  DSLTrans.
The resulting lifted version of \gmtoautosar is capable of transforming product
lines of legacy GM models to product lines of AUTOSAR models, while preserving
the correctness of individual product transformations.  
We also stress-tested the lifted \gmtoautosar to investigate the effect of the
size of the model and the variability complexity on the lifted transformation.
 Due to limitations to publication of sensitive industrial data, 
the product line we analyzed was created using publicly available
data 
 and calibrated with input from 
GM engineering.
%% our
%% industrial partners. 
%% \mf{Since Ramesh is a co-author, does it make sense to talk about "industrial
%% partners" in the third person? Should we use a different terminology, e.g. "GM
%% Engineering".}
% Our findings give further evidence to confirm our previous
% findings~\cite{salay14}, while illuminating several practical aspects of
% lifting. 



The rest of the paper is organized as follows: we introduce background on
to software product lines in Sec.~\ref{sec:bg:spl}. The \gmtoautosar
transformation is described in Sec.~\ref{s:gm2autosar} and
its lifting -- in
Sec.~\ref{section:lifting_dsltrans}. We discuss the experience of applying
the lifted transformation in Sec.~\ref{s:applyingLifted}. In
Sec.~\ref{section:lessons_learned} we present lessons learned and
Sec.~\ref{section:related_work} discusses related work.
We conclude in Sec.~\ref{section:conclusion} with a summary of
the paper and discussion of future work.

% \mf{
% Outline: in the intro there will be a high level description of this story:\\
% -- SPLs are used everywhere in automotive\\
% -- Migrating transformations are super important in the industry. \\
% -- Example: \gmtoautosar transf (with as little DSLTrans as necessary)\\ 
% -- Lifting \\
% This will also be the motivation (the transformation exists, it is useful for
% verification, validates previous work). 
% }
